The present invention relates to the development of service-oriented architecture applications, and, in particular, to Web service information management in service-oriented architecture applications.
SOA is a concept defining that an application can be composed of a series of independent, but collaborative subsystems or services. Such an architecture makes each service independent as long as telling other services the interfaces that need to be declared SOA makes various services available in a network through adopting those widely accepted standards (such as WSDL, XML, XSD, UDDI, and HTTP), and allows an application to find and bind active services (through UDDI and WSDL) for creating loosely coupled enterprise business processes. Thus, in SOA, a web service application may be composed of remote Web services in different domains, so that a service process across multiple business ranges can be used in place of a traditional layered application.
In SOA, a SOA application should meet the Service Level Agreement (SLA) to ensure the reliability and practicability of the service purchased by an enterprise so as to meet the quality requirements of the enterprise. In such a case, application developers and administrators need to know the detailed runtime information on the interaction between the SOA application service process and service participants, so it is necessary to acquire the runtime information of these web services. Thus, it can be seen that the runtime information on the interaction with the web services in a SOA application service process is very important for both the application development and Web service management.
FIG. 1 shows a traditional Web service information management model. In the traditional management model shown in FIG. 1, there is provided a management server that communicates directly with managed resources to acquire service information. As shown in FIG. 1, however, in a SOA application, a service requester usually uses a service broker or other mediators to access a service provider. Location transparency (a service requester can request a web service without knowing the location of the Web service) and the dynamic nature of the Web service interaction introduce great complexity into identifying the real location of the managed resources. Besides, as shown in FIG. 1, due to the above-mentioned distributed and loosely coupled features of a SOA application, services across geography, department and/or company boundaries may be involved in the SOA application service process. In such a case, because of the security policies in the various management domains, it is very difficult to communicate directly with services in these different management domains to collect their management information. Obviously, traditional management model is not suitable for a service-oriented architecture.
In an another aspect, in a service-oriented architecture, the execution process of a Web service may include a series of Web service invocations. Collecting the runtime information during the execution process of a Web service is very important for system management and maintenance. Next, a specific SOA application example will be used to explain the issue of information collection in a Web service execution process. FIG. 2 shows the service process of the application example. As shown in FIG. 2, a virtual catalog service in a store provides goods lookup service. When a service requester requests the service, the service will invoke physical catalog services deployed in the local store and central office according to the business logic and QoS requirements, wherein part of the services provided by the central office is provided by business partners. In the case of out of stock in the local store, the store would invoke the warehouse service of the central office. And the central office would invoke the service of the nearest distribution center which will return the stock situation. The services involved in this Web service process are determined in runtime and may be distributed in different management domains or physical locations.